In computer programming, application programs are often instrumented to monitor or measure the level of a product's performance, diagnose errors, etc. Application developers can implement instrumentation in the form of code instructions that monitor specific components in a system. Instrumentation can be necessary to review the performance of the application, and often incorporates data logging. Current data-logging techniques can use a logging framework that provides an application program interface (API), which can be used by application developers for logging data in their application. When the application is executed, the log API generates a log file having the logged data. Current data-logging techniques generally instrument the source code and this can have some disadvantages. For example, if the application is deployed into production and if the data to be logged has to be changed, e.g., more data items have to be logged, or a frequency with which the data is to be logged has to be changed, the application has to be recompiled with new logging code and then deployed again. This can be very inefficient and resource intensive.
For example, if the application is developed as a mobile application (“app”), the app with new logging code is “pushed” to user's mobile devices (“client computing devices”), and downloading and installing the app can consume resources, e.g., network bandwidth, processing capacity, time and effort of the user. Further, the problem can be amplified if the data logging is changed frequently, which may be the case in new apps or when new features are added to an app and different data may be needed for monitoring the performance of the app. Some users may not update their apps for prolonged periods, which can cause data collection gaps or even errors. One way to avoid such a problem is to configure the app to log all the data items. However, this is also inefficient as too much logging of data can consume the computing resources of the user's device, which can be a significant problem in mobile devices considering the resources, e.g., battery, memory, are limited. Moreover, users may not appreciate that a portion of their bandwidth is consumed by data that is transmitted to the server.
Further, some data-logging techniques continue logging data even when they may not be needed anymore. The number of users who use the product and/or the volume of data being logged can be different in different lifecycle stages of the product. The data-logging techniques continue to log the data without regard to the lifecycle of the product and therefore, can end up consuming resources of the mobile devices of the users. For example, when a product is in a product launch stage, more amount of data may need to be logged, e.g., as more data may be necessary to analyze the product and make any necessary changes to stabilize the behavior of the product, and as the product matures less amount of data may be needed, e.g., as the product is believed to be more stable. Further, as the product matures, the number of users using the product can be significantly large. However, the current data-logging techniques continue to log the data in the same way throughout the lifecycle of the product, which can generate significant volumes of data, thereby consuming the computing resources of the user's device.